Imagine filling in the fax number field of your friend Kim in your software organizer, such as Contact Manager by Microsoft, Redmond, Wash. But Kim has two fax numbers, one at home and one at the office. Or Kim is about to go on vacation, so for the next two weeks, there will be a different fax number. Or, Kim has two fax numbers at the office, one for a new, sophisticated, color fax machine which should be used if you want to send a color fax, and a plain one for black and white faxes.
Or imagine recording the source of a document you are adding to your group's document management system. Typically, the source is the person who wrote and sent you the document, but the document may be written by one person and sent to you by another, or the document consists of several parts, each written by a different person. Or the document is an official document from an organization, and both the organization and the individual who prepared the document are sources, in different senses.
Current information systems having a computer readable medium generally do not adequately address many of these situations. Typically, information systems require a system designer to prescribe a data model with a specific data structure. Traditional styles of data structures, such as relational structures, or entity-relationship structures, provide a fixed data structure in a database. For example, the only information that users can store or access in a relational data model are those listed as columns in a table. Typically, the information in each column depends on a key or a set of information in a predetermined column. For example, FIG. 1A illustrates a typical relational database 100 with rows 101a-c and columns 102a-d. Each row includes the part number, name of the part, supplier of the part, and supplier address. A key is column 102a. 
System designers determine what kinds of information will be stored and accessed, select a particular level of detail for that information, and, most importantly, decide what each piece of information can depend on. This rigid data structure is maintained throughout the system, and users are required to make their interactions conform to this data structure.
While this rigid data structure may be useful in certain applications, it is much less appropriate for personal or collaborative information systems, including document management systems, where the user's task is much less defined, and their information might depend on any number of factors.
This means that typical relational databases can not always record important information and then provide it in response to queries. For example, if a user queried database 100 asking for suppliers of part # “5” and the “ACME” supplier was discontinuing part # “5” at the end of the year, a query to a rigid data structure would not provide the user with this valuable information.
Therefore, it is desirable to allow a user to store and retrieve information based on the circumstances of each situation. The user should also be able to define the level of detail of the stored information, and most importantly, the dependencies of the information. The information should be stored in a manner that minimizes memory usage and reduces the likelihood of erroneous data entry. The stored information should also enable a more informative response to a query.